home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0600.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.5 KB  |  84 lines
  1.  
  2. >I like the idea, and am glad to see people are now taking an interest in html
  3. >and forms.
  4.  
  5. Does this mean my wag at an example does jive with your ideas? I'm
  6. still not clear... especially on the protocol.
  7.  
  8. >Summarising what you suggest above:
  9. >
  10. >    <input name=FIELDNAME type=FIELDTYPE [width=FIELDWIDTH] [help=HELPUDI]>
  11. >
  12. >    FIELDNAME is a unique identifier for this form
  13. >    FIELDTYPE ::= "boolean" | "text" | "integer" | "float"
  14. >
  15. >    The [ ] brackets denote optional attributes.
  16.  
  17. Why not let's talk SGML, while we're at it? It's not so tough:
  18.  
  19. <!ENTITY % url "CDATA" -- this is kind of a DTD macro >
  20. <!ELEMENT input - O EMPTY>
  21. <!ATTLIST input
  22.     name ID #REQUIRED
  23.     type (boolean|text|integer|float) #REQUIRED
  24.     help %url; #implied
  25.     >
  26.  
  27. >Multiple choice items need a richer structure, e.g.
  28. >
  29. >    <select name=FIELDNAME type=CHOICETYPE [value=VALUE] [help=HELPUDI]>
  30. >        <choice>item 1
  31. >        <choice>item 2
  32. >        <choice>item 3
  33. >    </select>
  34. >
  35. >    CHOICETYPE ::= "radio" | "single" | "multiple"
  36.  
  37. <!ELEMENT select - - (choice+)>
  38. <!ATTLIST select
  39.     name ID #REQUIRED
  40.     type (radio|single|multiple) #REQUIRED
  41.     value IDREF #IMPLIED -- defaults to first choice --
  42.     help %url; #IMPLIED
  43.     >
  44. <!ELEMENT choice - - (%hypertext)+ -- see HTML DTD: text with A tags -->
  45. <!ATTLIST choice
  46.     id ID #IMPLIED -- select's value attribute points here --
  47.     value CDATA #IMPLIED -- defaults to element content --
  48.     >
  49.  
  50. >It is also useful to distinguish form decorations from output fields. I think
  51. >this can be adequately handled using the existing emphasis tags though.
  52.  
  53. I don't get it; what's an output field?
  54.  
  55. >How will the <queryform> tag take over from the <ISINDEX> mechanism? Right
  56. >now, the browser provides an input field and search button, but I assume that
  57. >in future, searchable documents will use the queryform approach instead.
  58. >
  59. >Forms generally involve additional ideas:
  60. >
  61. >    a)  expressions and queries for output fields
  62. >
  63. >    b)  edits (constraints) on input field values
  64. >
  65. >    c)  dependencies between fields
  66. >
  67. >These can all be handled by the server, albeit with a performance penalty as
  68. >perceived by the user.
  69.  
  70. Whoa! You mean there's a round trip every time the user enters a field?
  71. This implies a stateful connection between the client and server.
  72.  
  73. This isn't the model I had in mind at all! I thought it went:
  74.     * server sends whole form
  75.     * user interacts with client only to fill out form
  76.     * user instructs client to send completed form to server
  77.     * client translates user inputs using <QUERYFORM> element
  78.       and sends results to server in HTRQ data
  79.     * server processes query.
  80.  
  81. Dan
  82.  
  83.  
  84.